How does the Loadbalancer ADC Portal securely connect to your network?

The new Loadbalancer ADC Portal uses modern cryptographic technology that provides full end-to-end security. But how does it work? And how does it actually connect to your network??  

Secure two-way communication using WebSockets

All communication takes place via a secure WebSocket protocol (WSS) with mTLS. With mTLS, the client is required to present its certificate to the server (and visa versa). Hence mutual certificate authentication occurs. This double layer of authentication provides an additional layer of protection against impersonation attacks. And it is only once this two-way authentication has taken place that a secure connection is established, leading to the exchange of data.

Diagram 1: Bi-directional communication via encrypted WSS/mTLS

Within this encrypted WSS channel, there are two methods of communication:

1. Event-driven requests

Explicitly defined requests are sent as events to the Shuttle for added security and efficiency.

2. Remote HTTP proxy

This is WARP-enabled, remote HTTP proxy to your network. It allows you to see the web interface of your appliance and provides a facility to manage it, over an encrypted connection across the Loadbalancer ADC Portal network.

What do we mean by WARP?

WARP is a proxy that helps you connect to the internet while simultaneously optimizing and securing (i.e. encrypting) your connection, giving you access to you appliance, no matter where you are.

PGP encryption for extra security

In addition to the secure WebSocket encryption outlined above, the Portal also contains a second layer of security: PGP encryption.

Diagram 2: The PGP encryption chain

Once the initial mTLS handshake has been completed, the Shuttle then creates its own PGP keys, which are then used for communication and verification with the ADCs. However, before data can be transferred from the client to the Shuttle, it must first pass through an intermediary key. This Certificate Chain enables the receiver to verify that the sender and all Certificate Authorities are trustworthy.

Every user needs not only their own private key, but also a copy of the organization key to read the data that’s coming in from the Shuttle. This means new users will need to be invited by the organization to register, and actively given a copy of the organization key (as well as activating their own private user key). In this way it is the organization who is the owner of everything - not the user.

And with the potential for multiple levels of encryption using different keys, it would be almost impossible to decrypt what is imprinted on the public key without also being in possession of a private key. In this way, if someone were to compromise or intercept the messages being transmitted by the Shuttle, break the TLS encryption and obtain the encrypted PGP data, they would still need the Shuttle’s private key to be able to read it.

In this way, data communications are sent via the Shuttle which acts as an intermediary or sidecar agent. but the Shuttle is unable to read these messages. It's only role is to act as a vector to forward this information when, and only when, the private and public keys match.

Conclusion

The ADC Portal is built on a zero-trust security model and offers end-to-end encryption. This approach ensures all data within the Portal is always encrypted (both at rest and in transit) using a unique pair of organization and private keys, meaning Loadbalancer can never see or read your data, and all data encryption and decryption occurs within your own environment.

For more information on the Portal, book a meeting with our technical engineers.